前面的篇章大部分著重 DDD 的戰術設計，這篇來說說戰略設計。

功能型團隊

在導入 DDD 前，我們審視後發現，過去的開發項目並沒有完全滿足其他部門的需求，導致對於同一需求開發多次；然而，當初的規格都是按照其他部門的說明內容去開的，那怎麼還會這樣呢？

舉個例子，行銷部門說"我想要在網站上加成就系統"，接著 PM 開始問細節，要有幾個成就、頁面長這樣行不行等等，然後估時程、實作，實作完成後交付成果，最後行銷部門說： "好像沒有達到我們想要的目的"

這凸顯出了，我們的團隊其實是功能型團隊，其他部門說什麼我們就做什麼，但有時其實他們也不甚清楚想要什麼，導致做出來的東西並不能解決問題。

需求型團隊

假如連使用者都不清楚要甚麼了，開發團隊要怎麼知道呢？(通靈、讀心術)

以剛剛的例子，行銷部門說： "我想要在網站上加成就系統"，這時候就可以追問為甚麼想要成就系統——是想要吸引新用戶？還是想要讓用戶留在網站的時間長一點？那是不是可以透過其他方法達成目的，像是加強 SEO？

對於其他部門想要的開發不能照單全收，要抱著打破砂鍋問到底的精神去了解背後的需求，而 DDD 的戰略設計中就有許多好用的技巧可以達到這個目的，比如共通語言(Ubiquitous Language)可以讓所有人在同一頁上討論、事件風暴(Event Storming)可以完成每個人對流程的共識等等。

下一篇會繼續聊聊，關於改變開發流程，團隊遇到的一些彆扭事件。